Release 10.1A: OpenEdge Getting Started:
WebSpeed Essentials

SpeedScript and CGI wrappers

SpeedScript is an implementation of the Progress 4GL language that is primarily used to develop Web applications. Progress 4GL is inserted into HTML by using special HTML tags. When the WebSpeed compiler compiles this HTML, it converts it into a CGI wrapper automatically. You can also write CGI wrappers directly. SpeedScript includes a built-in Web server input/output (I/O) system that provides access to the CGI environment and Web page output stream for a Web request.

Note: SpeedScript supports extensions that allow the use of XML through SAX and the Document Object Model (DOM) interface. These extensions provide the basic input, output, and low-level data manipulation capabilities required to use data contained in XML documents. For more information about XML support, see OpenEdge Development: Programming Interfaces , which describes XML support in the context of the Progress 4GL. However, the information also applies to SpeedScript, which is based on the Progress 4GL.

See the following sources for more information regarding SpeedScript:

OpenEdge Development: Progress 4GL Reference — Describes the syntax of all SpeedScript language elements. Also identifies which language elements apply to the 4GL, to SpeedScript, or to both the 4GL and SpeedScript.
OpenEdge Development: Progress 4GL Handbook — Covers important programming concepts such as database locking and transaction rules, program block and resource scoping rules, and the use of persistent procedures.

Similarities between the 4GL and SpeedScript

The similarities between the 4GL and SpeedScript include:

Block structure and resource scoping rules are the same.
Database events (such as CREATE and DELETE) can be handled in the same way.
Database locking and database transaction rules are the same.
Both can use SmartDataObjects as data sources.
Both can use the AppServer to process requests.
Both can be written using the same AppBuilder tools (Procedure Window, the Section Editor, and the TreeView).

Differences between the 4GL and SpeedScript

Some important differences between SpeedScript programming and Progress 4GL programming are:

4GL applications are usually state-aware, while SpeedScript applications are often stateless. The distinction between state-aware and stateless applications is briefly discussed in OpenEdge Application Server: Developing WebSpeed Applications .
GUI widget events are not used in WebSpeed SpeedScript applications. Visual elements are handled by HTML, rather than as GUI widgets.
The preprocessor {&OUT} statement is used to output data to the HTML page, rather than the DISPLAY statement. For information, see OpenEdge Application Server: Developing WebSpeed Applications .
In SpeedScript, all terminal-focused I/O is replaced by a block mode Web-oriented I/O, where the SpeedScript frame is the block data structure. Therefore, I/O blocking statements, such as UPDATE or PROMPT-FOR, cannot be used in SpeedScript applications. Similarly, the I/O blocking options of statements like the MESSAGE (VIEW-AS ALERT-BOX) and PAUSE (MESSAGE) statements are ignored.
Very few Progress 4GL events apply to WebSpeed applications, except database events. The one essential event in SpeedScript is WEB-NOTIFY. However, in normal use, this event is handled exclusively by the agent control program (web-disp.p).
WAIT-FOR cannot be used for user input in SpeedScript applications.
Some procedures that are available through include files and the Insert Call button of the Section Editor are only appropriate for WebSpeed applications. Some of these are:
hidden-field-list
set-cookie
get-cookie

See the WebSpeed API reference in the online help for a list of the public APIs.

SpeedScript includes special extensions, including a virtual Web output device (“WEB”) to define Web page output streams to your Web server and the WEB-CONTEXT system handle to access the request environment. However, most of these extensions are wrapped in the API functions, method and event procedures, and preprocessor definitions provided with WebSpeed.

These examples also rely on SpeedScript preprocessor references, especially {&OUT} and {&DISPLAY}, to direct output to the WebSpeed-defined output stream, WebStream. You can find the definitions for these preprocessor references (and several others) in install-path/src/web/method/cgidefs.i. For more information on the {&DISPLAY} preprocessor reference, see OpenEdge Application Server: Developing WebSpeed Applications . For more information on the SpeedScript preprocessor and more advanced SpeedScript topics, see OpenEdge Development: Progress 4GL Handbook .

SpeedScript versus JavaScript

It is a common practice to use both SpeedScript and JavaScript when developing WebSpeed applications. SpeedScript has advantages for developing the business logic of applications, while JavaScript is a good programming tool for adding user interface elements to Web applications.

If you use either the Report or Detail templates in AppBuilder to create a WebSpeed Web object, you can view the resulting HTML source file and see a combination of SpeedScript and JavaScript. The templates will help you create SpeedScript to implement database queries and updates, and they will create JavaScript event handlers (like onMouseOver, onClick, etc.) to implement interactive features of the WebSpeed applications.

The <SCRIPT> tag for JavaScript employs the same syntax as the <SCRIPT> tag for Embedded SpeedScript, as shown:

<SCRIPT Language="JavaScript"> JavaScript Code </SCRIPT>

In some situations, you do not need a <SCRIPT> tag. JavaScript event handlers, for example, do not require a <SCRIPT> tag when they are used as an attribute to an HTML tag, as shown in the following example:

<BODY onLoad="alert(’Done’);">

Some other factors that you should keep in mind when using JavaScript in WebSpeed applications are:

End users of your WebSpeed application will be able to see your JavaScript code when they view HTML source in their browsers. They can see the HTML output that Embedded SpeedScript generates, but they do not see the actual SpeedScript source code. (This is because the SpeedScript code executes on the server side while the JavaScript executes on the client-side browser.)
No static or dynamic HTML can be generated from the JavaScript code that is between HTML <SCRIPT> tags.
SpeedScript is executed on the server side by the WebSpeed agent. JavaScript is executed on the client side by the Web browser.

Additional SpeedScript components

The WebSpeed development environment also contains the following components:

Method procedures — A set of standard SpeedScript procedures that provides a variety of services to Web objects. Some method procedures that duplicate API functions are supported for upward compatibility with earlier WebSpeed versions. Others provide unique services to some types of Web objects, such as main-lining the response to Web requests. Some of these you can customize for each Web object. The source for many of the standard method procedures resides in the utility object web-util.p under install-path/src/web/objects. The run-web-object procedure follows a protocol designed to ensure the integrity of the Web object, whether it is stateless or state-aware. This allows WebSpeed to manage Web objects in a consistent manner. The run-web-object method procedure is defined in the utility object, install-path/src/web/objects/web-util.p.
Control handlers — A special class of procedures that execute in response to pseudo events in HTML-mapping Web objects, and that you can customize. These pseudo event procedures include web.input and web.output. By overriding web.input and web.output, you can replace the default data movement between HTML field definitions and corresponding field objects for HTML-mapping Web objects. The default versions of these control handlers for each type of HTML field are located in the tagmap utilities under install-path/src/web/support. Each utility procedure understands how to convert data between a particular type of HTML form element and a SpeedScript field object of the corresponding type.
tagmap.dat — A file that contains default mappings between HTML form element types and SpeedScript field object types for HTML-mapping Web objects. Each entry in the file includes the location of the default web.input and web.output control handler procedure for the field mapping. This file is also where you can define your own mappings and custom tags for your application. This file resides in your WebSpeed installation directory (install-path/).
web-disp.p — The control program that runs on all WebSpeed agents and executes all Web objects. The SpeedScript source resides in install-path/src/web/object. It manages various transaction states that can affect the whole application. This SpeedScript procedure is included with the development environment because it is central to the operation of WebSpeed applications. How web-disp.p manages Web objects can affect how and when you might set and evaluate transaction states in each Web object. This program also initializes the utility object web-util.p (residing in the same directory), where most API functions and method procedures reside at run time. WebSpeed has a special set of procedure-calling conventions. The first convention relies on the run-web-object method procedure. This procedure is the standard method to execute a Web object from within another procedure. It is also the basic method web-disp.p uses to execute Web objects in response to Web requests.